Executing transactions secured user credentials

ABSTRACT

In some implementations, a method includes interfacing a mobile device including a GUI. User credentials used to execute transactions with contactless devices are securely stored and associated with one or more enterprises. The secure memory includes master credentials and a master security framework that enables enterprises to store or update user credentials and associated security frameworks. Displays associated with the user credentials are dynamically generated and presented through the GUI of the mobile device. Wireless transactions are executed with contactless devices using the selectable user credentials.

CLAIM OF PRIORITY

This application is a continuation application of and claims priority toU.S. patent application Ser. No. 13/108,717, filed on May 16, 2011,which is a continuation application of and claims priority to U.S.patent application Ser. No. 12/206,564, now U.S. Pat. No. 7,942,337,filed on Sep. 8, 2008, which claims priority under 35 USC §119(e) toU.S. Patent Application Ser. No. 60/971,813, filed on Sep. 12, 2007, theentire contents of these applications are hereby incorporated byreference.

TECHNICAL FIELD

This invention relates to network communications and, more particularly,to executing transactions using secured user credentials.

BACKGROUND

Portable electronic devices and tokens have become an integrated part ofthe regular day to day user experience. There is a wide variety ofcommon portable and handheld devices that users have in their possessionincluding communication, business and entertaining devices such as cellphones, music players, digital cameras, smart cards, memory token andvariety of possible combinations of the aforementioned devices andtokens. All of these devices share the commonality that consumer areaccustomed to carrying them with them most of the time and to mostplaces. This is true across the various demographics and age groupsregardless of the level of the sophistication of the consumer, their agegroup, their technical level or background.

These common handheld devices offer options for expandable memory. MicroSecure Digital (microSD) is the popular interface across high-endcellphones while SD and MultiMediaCard (MMC) interfaces are alsoavailable in limited models. MicroSD is the least common denominatorsupported by the majority of these devices and tokens (in terms ofsize). In addition, adaptors are available to convert a MicroSD intoMiniSD, SD, MMC and USB Although most popular MP3 player (iPOD) offer'sa proprietary interface, competing designs do offer standard interfaces.Digital cameras offer mostly SD and MMC while extreme Digital (xD) isanother option. Micro and Mini versions of these interfaces are alsoavailable in several models. Mini-USB is increasingly available acrosscellphones, digital cameras and MP3 players for synchronization withlaptops.

SUMMARY

In some implementations, a method includes interfacing a mobile deviceincluding a GUI. User credentials used to execute transactions withcontactless devices are securely stored and associated with one or moreenterprises. The secure memory includes master credentials and a mastersecurity framework that enables enterprises to store or update usercredentials and associated security frameworks. Displays associated withthe user credentials are dynamically generated and presented through theGUI of the mobile device. Wireless transactions are executed withcontactless devices using the selectable user credentials.

The details of one or more embodiments of the invention are set forth inthe accompanying drawings and the description below. Other features,objects, and advantages of the invention will be apparent from thedescription and drawings, and from the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 is an example transaction system in accordance with someimplementations of the present disclosure;

FIG. 2 is an example transactions system that transmits transactioninformation through a cellular core network;

FIG. 3 is an example transaction card of FIG. 1 in accordance with someimplementations of the present disclosure;

FIG. 4 is an example intelligent card that selectively switching anantenna;

FIG. 5 is another example transaction system in accordance with someimplementations of the present disclosure;

FIG. 6 is a schematic diagram illustrating personalization processes ofintelligent cards;

FIGS. 7A and B is a flow chart illustrating an example method forinitialize an intelligent card;

FIGS. 8A-C are an example call flow illustrating call sessions with anintelligent card;

FIG. 9 is a flow chart illustrating an example method for activating atransaction card;

FIG. 10 illustrates an example memory for storing a plurality of usercredentials in an intelligent card; and

FIG. 11 is a flow chart illustrating an example method for dynamicallyswitching between user accounts.

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

FIG. 1 is a block diagram illustrating an example transaction system 100for wirelessly executing transactions with different enterprises using asingle intelligent card. For example, the system 100 may include asingle micoSecureDigital (microSD) card that executes transactions withdifferent enterprises (e.g., financial institutions) independent of amobile host device. For example, a single microSD card may execute apayment transaction with a financial institution, an access controltransaction with a enterprise network, a ticket purchase transactionwith a transit authority and/or an identity validation transaction witha government agency. In such implementations, each of the transactionscan securely identify a user and user privileges with respect to theservices being received from the different enterprises. Aside frommicroSD, the system 100 may include other mass storage interfaces thatconnect an intelligent card to a host device such as, for example,MultiMediaCard (MMC), SD, Universal Serial Bus (USB), Firewire, and/orothers. A host device may include a cellphone, a smartphone, a PersonalDigital Assistant (PDA), a MPEG-1 Audio Layer 3 (MP3) device, a digitalcamera, a camcorder, a client, a computer, and/or other device thatincludes, for example, a mass memory interface. In some implementations,an intelligent card can be a card that inserts into a host device andexecutes transactions independent of the host device. In executingtransactions, the intelligent card may use a dual interface thatconnects to both the host device through a physical interface (e.g., SD,MMC, USB) and external devices through a wireless connection (e.g., NFC,ISO 14443, Bluetooth). The intelligent card may control or otherwiseoperate one or more hardware components of the mobile host device (e.g.,display, cellular radio technology) using the physical interface andwirelessly communicate with access terminals using the wirelessinterface. In some implementations, the intelligent card includes aplurality of user credentials with each identity set associated with adifferent institution. For example, the intelligent card may store usercredentials for a credit card, a debit card, a prepaid card, a giftcard, a checking account, and/or other user accounts. In addition, theintelligent card may also store user credentials for other applicationssuch as loyalty (points for purchase), airline (access to clubs,check-in), state (driving license), memberships (clubs) and/or otherswhere user credentials are used to identify user so that goods and/orservices can be provided. By storing multiple user credentials in asingle intelligent card, the system 100 may execute transactions withdifferent institutions without requiring multiple instruments. In otherwords, a single intelligent card may operate as a logical wallet thatlocally stores information for different user accounts and switchesbetween the different user accounts in response to at least an event. Byproviding an intelligent card, the system 100 may wirelessly executetransactions with institutions without either requiring additionalhardware, software, and/or firmware and/or without requiring changes toexisting hardware, software, and/or firmware for reader terminals toenable a user to wirelessly execute a transaction. In addition, thesystem 100 may eliminate, minimize or otherwise reduce the number ofinstruments possessed by an individual to execute transactions usingdifferent user accounts. In other words, the intelligent card mayoperate as a plurality of different instruments but implemented as asingle device.

At a high level, the system 100 includes an enterprise 102 and clients104 a and 104 b coupled to institutions 106 through a network 108. Whilenot illustrated, the system 100 may included several intermediaryparties between the institution 106 and the network such as, forexample, a transaction acquirer and/or a payment network host. Theenterprise 102 includes a mobile device 110 a having a transaction card112 a and an access point 114 that executes transactions with customers.The access point 114 includes a Graphical User Interface (GUI) 109 forpresenting information to and/or receiving information from users. Insome implementations, the access point 114 can wirelessly transmit arequest to execute a transaction to the transaction card 112. Thetransaction card 112 may transmit authentication information to theaccess point 114. The client 104 includes the GUI 115 for presentinginformation associated with the system 100. The client 104 a includes acard reader 116 that interfaces the transaction card 112 c with theclient 104 a. The institution 106 may authorize the transaction based,at least in part, on information transmitted by the transaction card112. The mobile device 110 includes a GUI 111 for presenting informationassociated with user transactions.

The enterprise 102 is generally at least a portion of an enterprisehaving a physical presence (e.g., building) for operations. For example,the enterprise 102 may sell goods and/or services at a physical location(e.g., a brick-and-mortar store) directly to customers. In this example,the enterprise 102 buys or otherwise receives goods (e.g., produce) fromdistributors (not illustrated) and then may sell these goods tocustomers, such as users of the mobile device 110. In general, theenterprise 102 may offer face-to-face experiences with customers inproviding goods and/or services. For example, the enterprise 102 may bea click-and-mortar store such that a user selects a good or serviceusing the Internet and purchases and receives the good or service at theenterprise 102. The enterprise 102 may provide one or more of thefollowing services associated with goods: inventory, warehousing,distribution, and/or transportation. As a result, the enterprise 102 maynot immediately distribute goods received from distributors. Theenterprise 102 may include a single retail facility, one or more retailfacilities at a single geographic location, and/or a plurality of retailfacilities geographically distributed. In some cases, two or moreentities may represent portions of the same legal entity or affiliates.For example, the enterprise 102 and distributors may be departmentswithin one enterprise. In summary, the enterprise 102 may wirelesslyexecute financial transactions with the mobile device 110.

Each mobile device 110 comprises an electronic device operable tointerface with the transaction card 112 a. For example, the mobiledevice 110 may receive and transmit wireless and/or contactlesscommunication with the system 100. As used in this disclosure, themobile devices 110 are intended to encompass cellular phones, dataphones, pagers, portable computers, SIP phones, smart phones, personaldata assistants (PDAs), digital cameras, MP3 players, camcorders, one ormore processors within these or other devices, or any other suitableprocessing devices capable of communicating information with thetransaction card 112. In some implementations, the mobile devices 110may be based on a cellular radio technology. For example, the mobiledevice 110 may be a PDA operable to wirelessly connect with an externalor unsecured network. In another example, the mobile device 110 maycomprise a laptop that includes an input device, such as a keypad, touchscreen, mouse, or other device that can accept information, and anoutput device that conveys information associated with a transactionwith the enterprise 102, including digital data, visual information, orGUI 111.

The GUI 111 comprises a graphical user interface operable to allow theuser of the mobile device 110 to interface with at least a portion ofthe system 100 for any suitable purpose, such as executing transactionsand/or and presenting transaction history. Generally, the GUI 111provides the particular user with an efficient and user-friendlypresentation of data provided by or communicated within the system 100and/or also an efficient and user-friendly means for the user toself-manage settings and access services offered by the institution 106.The GUI 111 may comprise a plurality of customizable frames or viewshaving interactive fields, pull-down lists, and/or buttons operated bythe user. The term graphical user interface may be used in the singularor in the plural to describe one or more graphical user interfaces andeach of the displays of a particular graphical user interface. The GUI111 can include any graphical user interface, such as a generic webbrowser or touch screen, that processes information in the system 100and presents the results to the user.

The transaction card 112 can include any software, hardware, and/orfirmware configured to wirelessly execute transactions with the accesspoint 114 using one of a plurality of selectable user accounts. Forexample, the transaction card 112 may select user credentials associatedwith one of the plurality of selectable user accounts (e.g., financialaccounts) and execute a contactless transaction with the access point114 using the selected account and independent of the mobile device 110a. In other words, the transaction card 112 may wirelessly executetransactions without aspects of the transaction being executed by themobile device 110. In addition, the transaction card 112 maylocally-store user credentials and/or applications (e.g., paymentapplications, access applications) for a plurality of selectable useraccounts. The transaction card 112 may dynamically switch between usercredentials and payment applications in response to at least an event. Aswitching event may include a selection from a user through the GUI 111,completion of a transaction, detection of a type of signal, determininga type of purchase (e.g., groceries, clothes), change in geographic area(e.g., GPS), and/or other events. The different user accounts mayinclude a credit card account (e.g., Visa, MasterCard), a retail account(e.g., Target, Dillard's), a prepaid card, a gift card, a bank card(e.g., Bank of America), an airline card, an identity card, a drivinglicense, and/or others. In some implementations, the transaction card112 may include user credentials for any combination of financial,retail, airline, corporate, state and/or other accounts. In someimplementations, the transaction card 112 may locally-store applicationsfor the plurality of selectable user accounts. For example, thetransaction card 112 may execute a different application for each of thedifferent user credentials. The different applications may executetransactions using different reader infrastructures, formats, protocols,encryption, type/structure of user credentials exchanged with theterminal, and/or other aspects.

The transaction card 112 may execute transactions with the access point114 using short range signals such as NFC (e.g., ISO 18092/ECMA 340),ISO 14443, ISO 15693, Felica, MiFARE, Bluetooth, Ultra-wideband (UWB),Radio Frequency Identifier (RFID), and/or other signals compatible withretail payment terminals (e.g., access point 114). In someimplementations, the transaction card 112 may include one or morechipsets that execute an operating system and security processes toindependently execute the transaction. In doing so, the mobile device110 does not require additional hardware, software, and/or firmware towirelessly execution a transaction with the A access point 114 such asan NFC transaction. In some implementations, the transaction card 112may execute one or more of the following: dynamically switch betweenuser credentials and/or applications in response to at least one or moreevents; wirelessly receive a request from the access point 114 toexecute a transaction and/or transmit a response; translate betweenwireless protocols and protocols compatible with the transaction card112; translate between transaction-card protocols and protocolscompatible with mobile device 110; present and receive information(e.g., PIN request, PIN) from the user through the GUI 111; decrypt andencrypt information wirelessly transmitted between the transaction card112 and the access point 114; execute applications locally stored in thetransaction card 112; selectively switch the antenna of the transactioncard 112 on and off based, at least in part, on one or more events;execute authentication processes based, at least in part, on informationreceived, for example, through the GUI 111; transmit a host signature toaccess point 114 in response to at least a transaction challenge; store,at least in part, details of the transaction executed between the card112 and the access point 114; generate and/or present alerts (e.g.,audio-visual alerts) to the user through the GUI 111; generate and/ortransmit wireless-message alerts to the institution 106 using the mobiledevice 110 if cellular capable; and/or others. In some implementations,the transaction card 112 may initiate a transaction in response to atleast a user selecting a graphical element in the GUI 111. Thetransaction card 112 may initiate a transaction with the access point114 in response to at least wireless request transmitted by the accesspoint 114. In some implementations, the transaction card 112 mayselectively switch the antenna between an on and off state in responseto one or more events. The one or more events may include a userrequest, completion of transaction, insertion of card 112 differentmobile device, location change, timer events, detection of incorrect PINentered by the user, change of wireless network that the device isconnected to, message received from the institution 106 using wirelesscommunication methods such as SMS, and/or other events. For example, thetransaction card 112 may receive one or more commands to switch theantenna off from a cellular network (not illustrated) through the mobiledevice 110.

In regards to translating between protocols, the transaction card 112may process information in, for example, ISO 7816, a standard securityprotocol, and/or others. In this case, the transaction card 112 maytranslate between an NFC protocol (e.g., ISO 18092) and thetransaction-card protocol. In addition, the transaction card 112 mayinterface the mobile device 110 through a physical interface such asMicroSD, Mini-SD or SD. In regard to security processes, the transactioncard 112 may implement one or more encryption algorithms to securetransaction information such as card number (e.g., credit card number,debit-card number, bank account number), PIN, and/or other securityrelated information. The security related information may include anexpiry date, card verification code, user name, home phone number, userzip code and/or other user information associated with verifying anidentity of the card holder. In some implementations, the transactioncard 112 may execute private key (symmetric algorithms) such as DES,TDES and/or others or public key (asymmetric algorithms) such as RSA,elliptic curves, and/or others. In addition, the transaction card 112may include memory (e.g., Flash, EEPROM) for storing user data,applications, offline Webpages, and/or other information. In regards toapplications, the transaction card 112 may execute a locally storedapplication and present information to and received information from theuser through the GUI 111. For example, the transaction card 112 mayexecute an application used to synchronize an account balance with theinstitution 106 using the GUI 111 and the mobile device 110.Alternatively or in addition to applications, the transaction card 112may present offline Web pages to the user using the GUI 111. In responseto initiating a transaction, the transaction card 112 may automaticallypresent an offline Web page through the GUI 111. In someimplementations, the offline Web page can be associated with ainstitution 106. In some implementations, the transaction card 112 canbe backward compatible and operate as a mass storage device. Forexample, if the wireless interface of the transaction card 112 is notavailable or deactivated, the transaction card 112 may operate as a massstorage device enabling users to access data stored in the memorycomponent (e.g., Flash). In some implementations, the transaction card112 can execute a set of initialization commands in response to at leastinsertion into the mobile device 110. These initialization commands mayinclude determining device related information for the mobile device 100(e.g., phone number, signature, connected network information, locationinformation and other available properties), determining user relatinginformation (e.g., PIN code, activation code), incrementing counters,setting flags and activating/deactivating functions according topre-existing rules and/or algorithms.

In some implementations, the transaction card 112 may automaticallyexecute one or more fraud control processes. For example, thetransaction card 112 may identify an operational change andautomatically transmit a notification to the financial institutionbased, at least in part, on the identified change. The transaction card112 may execute two fraud control processes: (1) determine a violationof one or more rules; and (2) automatically execute one or more actionsin response to at least the violation. In regards to rules, thetransaction card 112 may locally store rules associated with updates tooperational aspects of the transaction card 112. For example, thetransaction card 112 may store a rule indicating a change in mobile hostdevice 110 is an operational violation. In some implementations, thetransaction card 112 may store rules based, at least in part, on updatesto one or more of the following: phone number of host device 110; MACaddress of host device 110; network wirelessly connected to host device110; location of host device; and/or other aspects. In response to oneor more events matching or otherwise violating rules, the transactioncard 112 may execute one or more processes to substantially prevent orotherwise notify the institutions 106 of potentially fraudulentactivity. For example, the transaction card 112 may execute a command toblock an associated user account and/or the transaction card 112.Alternatively or in addition, the transaction card 112 may transmit acommand to the institution 106 to call the mobile host device 110. Insome implementations, the transaction card 112 may execute a commandbased, at least in part, on an event type. In some examples, thetransaction card 112 may initiate a call with the institution 106 inresponse to at least a change in number of the host device 110. In someexamples, the transaction card 112 may re-execute the activation processin response to at least a specified event type. In some implementations,the transaction card 112 may execute a command to disconnect the GUI 111from the transaction card 112. The transaction card 112 may present adisconnection notification through the GUI 111 prior to executing thecommand. In some implementations, the transaction card 112 may transmita command to the institution 106 to deactivate an account associatedwith the card 112.

In some implementations, the access point 114 may transmit a transactionrequest 117 to the transaction card 112 for information to generate anauthorization request 118. In response to at least the transactionrequest, the transaction card 112 may transmit one or more transactionresponses 119 identifying information associated with a user account. Insome implementations, the access point 114 may transmit a request 118 toauthorize a transaction to the institution 106. The authorizationinformation may include an account number, a transaction amount, usercredentials, and/or other information. In response to at least thetransaction request 118, the institution 106 may transmit anauthorization response 120 to the access point 114. In someimplementations, the access point 114 may transmit the response 120 tothe transaction card 112. The transaction response 120 may include, forexample, a receipt presentable to the user through the GUI 111 a. Insome implementations, the institution 106 may transmit the authorizationresponse 120 to the mobile device through a cellular core network (seeFIG. 2). In this implementation, the institution 106 may have stored theassociation between the mobile device 110 and the transaction card 112during the user sign-up process, automatically upon user activation ofthe card 112 when, for example, the card 112 is initially inserted intothe mobile device 110, and/or other event. In the illustratedimplementation, the access point 114 includes the GUI 109.

The GUI 109 comprises a graphical user interface operable to allow theuser of the access point 114 to interface with at least a portion of thesystem 100 for any suitable purpose, such as a user entering transactioninformation (e.g., PIN, transaction acceptance) and/or and presentingtransaction information (e.g., transaction amount). Generally, the GUI109 provides the particular user with an efficient and user-friendlypresentation of data provided by or communicated within the system 100and/or also an efficient and user-friendly means for the user toinitiate a wirelessly transaction with the transaction card 112. The GUI109 may present a series of screens or displays to the user to, forexample, accept a transaction and enter security information such as aPIN.

In some implementations, the transaction card 112 can be implementeddifferently. The transaction card 112 may be implemented as a KeyFOB andremains live outside the mobile device 110 as a FOB. In this case, thetransaction card 112 may be passive and powered from an inductionmagnetic field generated by the access point 114. The transaction card112 may be implemented in the form of an industrial integrated circuitchip for mounting on a PCB or IC chip. In some implementations, thetransaction card 112 may be implemented in the form of a self containeddesktop standalone unit powered by external AC adapter or stand alonebox. In some implementations, the transaction card 112 can beimplemented as an external attachment to a mobile device 110 (e.g.,case) and connected to the mobile device using a peripheral interfacesuch as USB, serial port, the iDock apple proprietary interface, and/orother interface.

In some implementations, the transaction card 112 may operate inaccordance with one or more of the following modes: active cardemulation; active reader; self train; killed; memory; and/or othermodes. The transaction card 112 may operate active-card-emulation modeto convert the mobile device 110 to a contactless payment device loadedwith a financial vehicle (FV) that may be, for example, a credit card, adebit card, a gift card and/or other retail payment product. In thismode, the transaction card 112 may execute transactions at any capableretail payment terminal (e.g., access point 114) that acceptscontactless payment transactions. For example, such terminals may becontactless-enabled terminals currently being deployed by merchantsunder MasterCard's paypass or Visa's paywave programs. After the antennaof the transaction card 112 is activated in this mode, a merchantterminal may detect the presence of the transaction card 112 and promptthe user to authorize a transaction such as by entering a PIN, signingon a terminal interface, confirming the amount of the transaction,and/or other action. In this mode, such transactions may be handled as anormal credit card present transaction. In this implementation, neitherthe terminal nor the financial institution may require additionalsoftware to execute the transaction. In addition, the transaction card112 in this mode may be used for other applications such as physicalaccess control (to open gates either in a corporate environment or in atransit environment), logical access control (to request network accessvia a PC), application access control (to buy access for amenities suchas transportation, movies or wherever payment needs to be made to gainaccess to a facility), and/or other applications.

In the active-reader mode, the transaction card 112 may convert themobile device 110 to a contactless reader device capable of receivingdata when in range of a transmitting terminal (e.g., access point 114).In some implementations, this mode can require special NFC hardware withreader mode capability as part of the transaction card 112. In the eventthat the mobile device 110 is proximate (e.g., 10 cm or less) atransmitting terminal, the reader mode of the transaction card 112 mayactivated and prompt the user for authorization to receive data throughthe GUI 111. This mode may only be suitable for mobile devices 110 witha UI element, such as an OK button and a screen, an LED to indicate thatdata reception is being requested, and/or other interfaces. Once theuser authorizes the transmission, the transaction card 112 in this modemay receive, and locally store, process and may execute a transactionand/or forward received data to another entity. For example, thetransaction card 112 in this mode may receive content throughpromotional posters, validating the purchase of a ticket, and/or others.For example, the transaction card 112 in this mode may function as amobile POS terminal receiving transaction information from a plasticcontactless card/FOB and instructing the mobile device 110 to prepare atransaction authorization request for the institution 106 through acellular core network. Once the institution 106 authorizes thetransaction, the mobile device 110 may display the confirmation of thetransaction to the user through the GUI 111.

In regards to the self-train mode, the transaction card 112 may executea version of the reader mode. In some implementations, the self-trainmode can be activated by a special action (e.g., a needle point press toa small switch, entry of an administrative password via the GUI 111). Inresponse to at least activating this mode, the transaction card 112 maybe configured to receive personalization data over, for example, theshort range wireless interface from another peer transaction card suchas the plastic contactless cards compliant with this functionality andissued by the institution 106. Personalization data received in thismode may include encrypted FV information that is stored in securedmemory of the transaction card 112. In some implementations, thetransaction card 112 in this mode may receive the FV information througha contactless interface of a transmitter and/or others. The transactioncard 112 may then synthesize the FV information that corresponds to theuser account and personalize the secure element. The self-train mode maybe used to re-personalize the plug-in in the field. In someimplementations, all previous data can be deleted if the self-train modeis activated. The self-train mode may be a peer-to-peer personalizationmode where the card 112 may receive personalization information fromanother transaction card 112. This mode may not include a factory, storeand/or Over-The-Air (OTA) personalization scenarios which may be serverto client personalization scenarios. In some implementations, theself-train mode may be a peer-to-peer personalization mode where thetransaction card 112 receives personalization information from anothertransaction card. Since two transaction cards 112 are used in this mode,this mode is not a server to client personalization scenario as with afactory, store, and OTA personalization.

In regards to the killed mode, the transaction card 112 may permanentlydeactivate the contactless interface. In some implementations, thekilled mode is activated through the physical interface with the mobiledevice 110 such as a microSD interface. In response to at least theactivation of the killed mode, the transaction card 112 may permanentlybehaves as a mass memory stick. In the event that the reset needle pointis pressed, the transaction card 112 may, in some implementations, notbe made to enter any other modes. In addition, the transaction card 112may delete financial content in memory in response to at least this modebeing activated. In some implementations, wireless operators may usethis mode to delete data from a transaction card 112 physically lost.

In regards to the memory mode, the transaction card 112 may operate as amass memory stick such that the memory is accessible throughconventional methods. In some implementations, the transaction card 112may automatically activate this mode in response to at least beingremoved from the host device, inserted into a non-authorized hostdevice, and/or other events. The transaction card 112 may be switched toactive mode from the memory mode by, for example, inserting the card 112into an authorized device or may be switched from this mode into theself-train mode to re-personalize the device for a new host device or anew user account.

In some implementations, the transaction card 112 may bere-personalized/updated such as using software device management processand/or a hardware reset. For example, the user may want tore-personalize the transaction card 112 to change host devices, to havemultiple host devices, and/or other reasons. In regards to the softwaredevice management, the user may need to cradle the new host device withthe transaction card 112 inserted to launch the software devicemanagement application. In some implementations, the software managementapplication can be an application directly installed on the client 104,integrated as a plug-in to a normal synchronization application such asActiveSync, available via a browser plug-in running on the plug-inprovider's website, and/or other sources. The user may log into theapplication and verify their identity, and in response to verification,the application may allow access to a devices section in the devicemanagement application. The device management application may read thetransaction card 112 and display the MAC addresses, signatures of thedevices that he has inserted his plug-in to, and/or other devicespecific information. The mobile device 110 may be marked as active andthe host device may be shown as disallowed or inactive. The applicationmay enable the user to update the status of the new host device, and inresponse to at least the selection, the device management applicationmay install the signature on the new host device and mark update thestatus as allowable in secure memory of the transaction card 112. Theuser may be able to also update the status of the mobile device 110 todisallowed. Otherwise, both devices may be active and the transactioncard 112 may be switched between the two devices. In regards to thehardware reset process, the use may use the reset needle point press onthe physical transaction card 112 to activate the self-train mode. Inthis mode, the financial data may be deleted and have to be reloaded.When the transaction card 112 is inserted into the new host device, theprovisioning process may begin as discussed above.

The access point 114 can include any software, hardware, and/or firmwarethat wirelessly receive account information for executing a transactionwith one or more institutions 106. For example, the access point 114 maybe an electronic cash register capable of wirelessly transmittingtransaction information with the transaction card 112 a. The accesspoint 114 may transmit information in one or more the following formats:14443 Type A/B, Felica, MiFare, ISO 18092, ISO 15693; and/or others. Thetransaction information may include verification information, checknumber, routing number, account number, transaction amount, time,driver's license number, merchant ID, merchant parameters, credit-cardnumber, debit-card number, digital signature and/or other information.In some implementations, the transaction information may be encrypted.In illustrated implementation, the access point 114 can wirelesslyreceive encrypted transaction information from the transaction card 112and electronically send the information to one or more of theinstitutions 106 for authorization. For example, the access point 114may receive an indication that a transaction amount has been accepted ordeclined for the identified account and/or request additionalinformation from the transaction card 112.

As used in this disclosure, the client 104 are intended to encompass apersonal computer, touch screen terminal, workstation, network computer,a desktop, kiosk, wireless data port, smart phone, PDA, one or moreprocessors within these or other devices, or any other suitableprocessing or electronic device used for viewing transaction informationassociated with the transaction card 112. For example, the client 104may be a PDA operable to wirelessly connect with an external orunsecured network. In another example, the client 104 may comprise alaptop that includes an input device, such as a keypad, touch screen,mouse, or other device that can accept information, and an output devicethat conveys information associated with transactions executed with theinstitutions 106, including digital data, visual information, or GUI115. In some implementations, the client 104 b can wirelesslycommunicate with the transaction card 112 b using, for example, an NFCprotocol. In some implementations, the client 104 a includes a cardreader 116 having a physical interface for communicating with thetransaction card 112 c. In some implementations, the card reader 116 mayat least include an adapter 116 b that adapts the interface supported bythe client 104 (e.g., USB, Firewire, Bluetooth, WiFi) to the physicalinterface supported by the card 112 (e.g., SD/NFC). In this case, theclient 104 a may not include a transceiver for wireless communication.

The GUI 115 comprises a graphical user interface operable to allow theuser of the client 104 to interface with at least a portion of thesystem 100 for any suitable purpose, such as viewing transactioninformation. Generally, the GUI 115 provides the particular user with anefficient and user-friendly presentation of data provided by orcommunicated within the system 100. The GUI 115 may comprise a pluralityof customizable frames or views having interactive fields, pull-downlists, and/or buttons operated by the user. The term graphical userinterface may be used in the singular or in the plural to describe oneor more graphical user interfaces and each of the displays of aparticular graphical user interface. The GUI 115 can include anygraphical user interface, such as a generic web browser or touch screen,that processes information in the system 100 and presents the results tothe user. The institutions 106 can accept data from the client 104using, for example, the web browser (e.g., Microsoft Internet Exploreror Mozilla Firefox) and return the appropriate responses (e.g., HTML orXML) to the browser using the network 108. In some implementations, theGUI 111 c of the transaction card 112 c may be presented through the GUI115 a of the client 104 a. In these implementations, the GUI 115 a mayretrieve user credentials from the GUI 111 c and populate financialforms presented in the GUI 115 a. For example, the GUI 115 a may presenta form to the user for entering credit card information to purchase agood through the Internet, and the GUI 115 a may populate the form usingthe GUI 111 c in response to at least a request from the user.

Institutions 106 a-c can include any enterprise that may authorizetransactions received through the network 108. For example, theinstitution 106 a may be a credit card provider that determines whetherto authorize a transaction based, at least in part, on informationreceived through the network 106. The institution 106 may be a creditcard provider, a bank, an association (e.g., VISA), a retail merchant(e.g., Target), a prepaid/gift card provider, an internet bank, agovernment entity, a club, and/or others. In general, the institution106 may execute one or more of the following: receive a request toauthorize a transaction; identify an account number and othertransaction information (e.g., PIN); identify funds and/or a creditlimit associated with the identified account; identify access privilegesassociated with the user account; determine whether the transactionrequest exceeds the funds and/or credit limit and/or violates any otherrules associated with the account; transmit an indication whether thetransaction has been accepted or declined; and/or other processes. Inregards to banking, the institution 106 may identify an account number(e.g., bank account, debit-card number) and associated verificationinformation (e.g., PIN, zip code) and determine funds available to theaccount holder. Based, at least in part, on the identified funds, theinstitution 106 may either accept or reject the requested transaction orrequest additional information. As for encryption, the institution 106may use a public key algorithm such as RSA or elliptic curves and/orprivate key algorithms such as TDES to encrypt and decrypt data.

Network 108 facilitates wireless or wired communication between thefinancial institutions and any other local or remote computer, such asclients 104 and the access point 114. Network 108 may be all or aportion of an enterprise or secured network. While illustrated as singlenetwork, network 108 may be a continuous network logically divided intovarious sub-nets or virtual networks without departing from the scope ofthis disclosure, so long as at least a portion of network 108 mayfacilitate communications of transaction information between theinstitutions 106, the clients 104, and the enterprise 102. In someimplementations, network 108 encompasses any internal or externalnetwork, networks, sub-network, or combination thereof operable tofacilitate communications between various computing components in system100. Network 108 may communicate, for example, Internet Protocol (IP)packets, Frame Relay frames, Asynchronous Transfer Mode (ATM) cells,voice, video, data, and other suitable information between networkaddresses. Network 108 may include one or more local area networks(LANs), radio access networks (RANs), metropolitan area networks (MANs),wide area networks (WANs), all or a portion of the global computernetwork known as the Internet, and/or any other communication system orsystems at one or more locations.

FIG. 2 is a block diagram illustrating an example transaction system 200for wirelessly communicating transactions information using cellularradio technology. For example, the system 200 may wirelessly communicatea transaction receipt to a transaction card 112 using a mobile hostdevice 110 and cellular radio technology. In some implementations,cellular radio technology may include Global System for MobileCommunication (GSM), Code Division Multiple Access (CDMA), UniversalMobile Telecommunications System (UMTS), and/or any other cellulartechnology. The institutions 106 may assign one or more mobile hostdevices 110 to a transaction card 112 in response to one or more events.In some examples, the user may register the one or more mobile devices110 with the institution 106 in connection with, for example, requestingthe associated transaction card 112. In some examples, the transactioncard 112 may register the mobile host device 110 with the institution106 in response to at least an initial insertion into the device 110.Regardless of the association process, the system 100 may use thecellular capabilities of the host devices 110 to communicate informationbetween the institutions 106 and the transaction card 112. In using thecellular radio technology of the host device 110, the system 200 maycommunicate with the transaction card 112 when the card 112 is notproximate a retail device, such as the Access point 114 of FIG. 1.

In the illustrated implementation, the cellular core network 202typically includes various switching elements, gateways and servicecontrol functions for providing cellular services. The cellular corenetwork 202 often provides these services via a number of cellularaccess networks (e.g., RAN) and also interfaces the cellular system withother communication systems such as the network 108 via a MSC 206. Inaccordance with the cellular standards, the cellular core network 202may include a circuit switched (or voice switching) portion forprocessing voice calls and a packet switched (or data switching) portionfor supporting data transfers such as, for example, e-mail messages andweb browsing. The circuit switched portion includes MSC 206 thatswitches or connects telephone calls between radio access network (RAN)204 and the network 108 or another network, between cellular corenetworks or others. In case the core network 202 is a GSM core network,the core network 202 can include a packet-switched portion, also knownas General Packet Radio Service (GPRS), including a Serving GPRS SupportNode (SGSN) (not illustrated), similar to MSC 206, for serving andtracking communication devices 102, and a Gateway GPRS Support Node(GGSN) (not illustrated) for establishing connections betweenpacket-switched networks and communication devices 110. The SGSN mayalso contain subscriber data useful for establishing and handing overcall connections. The cellular core network 202 may also include a homelocation register (HLR) for maintaining “permanent” subscriber data anda visitor location register (VLR) (and/or an SGSN) for “temporarily”maintaining subscriber data retrieved from the HLR and up-to-dateinformation on the location of those communications devices 110 using awireless communications method. In addition, the cellular core network202 may include Authentication, Authorization, and Accounting (AAA) thatperforms the role of authenticating, authorizing, and accounting fordevices 110 operable to access GSM core network 202. While thedescription of the core network 202 is described with respect to GSMnetworks, the core network 202 may include other cellular radiotechnologies such as UMTS, CDMA, and others without departing from thescope of this disclosure.

The RAN 204 provides a radio interface between mobile devices and thecellular core network 202 which may provide real-time voice, data, andmultimedia services (e.g., a call) to mobile devices through a macrocell208. In general, the RAN 204 communicates air frames via radio frequency(RF) links. In particular, the RAN 204 converts between air frames tophysical link based messages for transmission through the cellular corenetwork 202. The RAN 204 may implement, for example, one of thefollowing wireless interface standards during transmission: AdvancedMobile Phone Service (AMPS), GSM standards, Code Division MultipleAccess (CDMA), Time Division Multiple Access (TDMA), IS-54 (TDMA),General Packet Radio Service (GPRS), Enhanced Data Rates for GlobalEvolution (EDGE), or proprietary radio interfaces. Users may subscribeto the RAN 204, for example, to receive cellular telephone service,Global Positioning System (GPS) service, XM radio service, etc.

The RAN 204 may include Base Stations (BS) 210 connected to Base StationControllers (BSC) 212. BS 210 receives and transmits air frames within ageographic region of RAN 204 (i.e. transmitted by a cellular device 102e) and communicates with other mobile devices 110 connected to the GSMcore network 202. Each BSC 212 is associated with one or more BS 210 andcontrols the associated BS 210. For example, BSC 212 may providefunctions such as handover, cell configuration data, control of RF powerlevels or any other suitable functions for managing radio resource androuting signals to and from BS 210. MSC 206 handles access to BSC 212and the network 108. MSC 206 may be connected to BSC 212 through astandard interface such as the A-interface. While the elements of RAN204 are describe with respect to GSM networks, the RAN 204 may includeother cellular technologies such as UMTS, CDMA, and/or others. In thecase of UMTS, the RAN 204 may include Node B and Radio NetworkControllers (RNC).

The contactless smart card 214 is a pocket-sized card with embeddedintegrated circuits that process information. For example, the smartcard 214 may wirelessly receive transaction information, process theinformation using embedded applications and wirelessly transmit aresponse. The contactless smart card 214 may wirelessly communicate withcard readers through RFID induction technology at data rates of 106 to848 kbit/s. The card 214 may wirelessly communicate with proximatereaders between 10 cm (e.g., ISO/IEC 14443) to 50 cm (e.g., ISO 15693).The contactless smart card 214 operates independent of an internal powersupply and captures energy from incident radio-frequency interrogationsignals to power the embedded electronics. The smart card 214 may be amemory card or microprocessor card. In general, memory cards includeonly non-volatile memory storage components and may include somespecific security logic. Microprocessor cards include volatile memoryand microprocessor components. In some implementations, the smart card214 can have dimensions of normally credit card size (e.g.,85.60×53.98×0.76 mm, 5×15×0.76 mm). In some implementations, the smartcard 214 may be a fob or other security token. The smart card 214 mayinclude a security system with tamper-resistant properties (e.g., asecure cryptoprocessor, secure file system, human-readable features)and/or may be configured to provide security services (e.g.,confidentiality of stored information).

In some aspects of operation, the institution 106 may wirelesslycommunicate with the mobile host device 110 using the cellular corenetwork 202. For example, the institution 106 may transmit informationto the mobile host device 110 in response to at least an event. Theinformation may include, for example, transaction information (e.g.,transaction receipt, transaction history), scripts, applications, Webpages, and/or other information associated with the institutions 106.The event may include completing a transaction, determining atransaction card 112 is outside the operating range of a access pointterminal, receiving a request from a user of the mobile host device,and/or others. For example, the institution 106 may identify a mobilehost device 110 associated with a card 112 that executed a transactionand transmit transaction information to the mobile host device 110 usingthe cellular core network 202. In using the cellular core network 202,the institutions 106 may transmit information to the transaction card112 without requiring an access point terminal being proximate to thecard 112. In addition or alternatively, the institution 106 may requestinformation from the mobile host device 110, the transaction card 112and/or the user using the cellular core network 202. For example, theinstitution 106 may transmit a request for transaction history to thecard 112 through the cellular core network 202 and the mobile hostdevice 110. In some implementations, the mobile host device 110 c mayoperate as a mobile Point of Sale (POS) terminal configured towirelessly execute transactions with the smart card 214. For example, avendor may be mobile (e.g., a taxi driver) and may include a mobile hostdevice 110 c with a transaction card 112 c. In this example, thetransaction card 112 c may wirelessly receive account information fromthe smart card 214 and transmit an authorization request to theinstitution 106 using the mobile host device 110 and the cellular corenetwork 202.

In some implementations, the system 100 may execute one or more of themodes discussed with respect to FIG. 1. For example, the transactioncard 112 may be re-personalized/updated using the cellular radiotechnology of the mobile host device 110. The user may want tore-personalize the transaction card 112 to change host devices, to havemultiple host devices, and/or other reasons. In regards to the softwaredevice management, the user may transmit to the institution 106 arequest to re-personalize the transaction card 112 using the cellularradio technology of the host device 110.

FIG. 3 illustrates is a block diagram illustrating an exampletransaction card 112 of FIG. 1 in accordance with some implementationsof the present disclosure. In general, the transaction card 112 includespersonalized modules that execute transactions (e.g., financial)independent of the mobile device 110. The illustrated transaction card112 is for example purposes only, and the transaction card 112 mayinclude some, all or different modules without departing from the scopeof this disclosure.

In some implementations, the transaction card 112 can include aninterface layer 302, an API/UI 304, a Web server 306, a real-timeframework 308, payment applications 310, value added applications 312,multiple user credentials 314, real-time OS 316, contactless chipset318, antenna control functions 320, antenna 322, institution memory 324,free memory 326, and a wallet management system 328. In someimplementations, a host controller includes the interface layer 302, heAPI/UI 304, the Web server 306, the real-time framework 308, thecontactless chipset 318, and the antenna control functions 320. In someimplementations, a security module includes the payment applications 310and the user credentials 314. The institution memory 324 and free memory326 may be contained in Flash. In some implementations, the contactlesschipset 318 may be integrated within the security module or operated asa standalone. The antenna 322 may be electronic circuitry.

The interface layer 302 includes interfaces to both the host device,i.e., physical connection, and the external world, i.e., wirelessconnection. In payment implementations, the wireless connection can bebased on any suitable wireless standard such as contactless (e.g., ISP14443 A/B), proximity (e.g., ISO 15693), NFC (e.g., ISO 18092), and/orothers. In some implementations, the wireless connection can use anothershort range wireless protocol such as Bluetooth, another proprietaryinterfaces used by retail payment terminals (Felica in Japan, MiFare inAsia, etc.), and/or others. In regards to the physical interface, theinterface layer 302 may physically interface the mobile device 110 usingan SD protocol such as MicroSD, Mini-SD or SD (full-size). In someimplementations, the physical interface may include a converter/adapterto convert between two different protocols based, at least in part, onthe mobile device 110. In some implementations, the mobile device 110may communicate using protocols such as USB, MMC, iPhone proprietaryinterface, or others.

The API/UI layer 304 can include any software, hardware, and/or firmwarethat operates as an API between the mobile device 110 and thetransaction card 112 and as the GUI 111. Prior to executingtransactions, the transaction card 112 may automatically install driversin the mobile device 110 in response to at least insertion. For example,the transaction card 112 may automatically install a MicroSD devicedriver in the device 110 to enable the transaction card 112 to interfacethe mobile device 110. In some implementations, the transaction card 112may install an enhanced device driver such as the a Mass Memory withRadio (MMR) API. In this implementation, the interface can drive a classof plug-ins that contain mass memory as well as a radio interface. TheMMR API may execute one or more of the following: connect/disconnectto/from the MMR controller (Microcontroller in the plug-in); transferdata using MM protocol (e.g., SD, MMC, XD, USB, Firewire); sendencrypted data to the MMR controller; receive Acknowledgement of Successor Error; received status word indicating description of error; turnradio on/off; send instruction to the transaction card 112 to turn theantenna on with specifying the mode of operation (e.g., sending mode,listening mode); transmit data such as send instruction to controller totransmit data via the radio; listen for data such as send instruction tocontroller to listen for data; read data such as send instruction tocontroller to send the data received by the listening radio; and/orothers. In some implementations, MMR can be compliant with TCP/IP. Insome implementations, API encapsulated ISO 7816 commands may beprocessed by the security module in addition to other commands.

In some implementations, the API can operate in accordance with the twoprocesses: (1) the transaction card 112 as the master and the mobiledevice 110 as the slave; and (2) the card UI as the master. In the firstprocess, the transaction card 112 may pass one or more commands to themobile device 110 in response to, for example, insertion of thetransaction card 112 into a slot in the mobile device 110, a transactionbetween the transaction card 112 and the access point 114, and/or otherevents. In some implementations, the transaction card 112 can requestthe mobile device 110 to execute one or more of following functions: GetUser Input; Get Signature; Display Data; Send Data; Receive Data; and/orothers. The Get User Input command may present a request through the GUI111 for data from the user. In some implementations, the Get User Inputmay present a request for multiple data inputs. The data inputs may beany suitable format such as numeric, alphanumeric, and/or other stringsof characters. The Get Signature command may request the mobile device110 to return identification data such as, for example, a phone number,a network code, a connection status, location information, Wi-Fibeacons, GPS data, and/or other device specific information. The DisplayData command may present a dialog to the user through the GUI 111. Insome implementations, the dialog can disappear after a period of time, auser selection, and/or other event. The Send Data command may requestthe mobile device 110 to transmit packet data using its own connectionto the external world (e.g., SMS, cellular, Wi-Fi). The Receive Datacommand may request the mobile device 110 to open a connection channelwith certain parameters and identify data received through theconnection. In some implementations, the command can request the mobiledevice 110 to forward any data (e.g., SMS) satisfying certain criteriato be forwarded to the transaction card 112.

In regards to the UI as master, the UI may execute one or more of thefollowing commands: Smart Card Command/Response; Activate/Deactivate;Flash Memory Read/Write; Send Data with or without encryption; ReceiveData with or without decryption; URL Get Data/URL Post Data; and/orothers. The security module commands may relate to security functionsprovided by the card and are directed towards the security module withinthe transaction card 112 (e.g., standard ISO 7816 command, proprietarycommands). In some implementations, the commands may include encryption,authentication, provisioning of data, creation of security domains,update of security domain, update of user credentials after verificationof key, and/or others. In some implementations, the commands may includenon security related smart card commands such as, for example, readtransaction history commands. The read transaction history command mayperform a read of the secure memory 324 of the transaction card 112. Insome implementations, certain flags or areas of the secure memory 324may be written to after security verification. The Activate/Deactivatecommand may activate or deactivate certain functions of the transactioncard 112. The Flash Memory Read/Write command may execute a read/writeoperation on a specified area of the non-secure memory 326. The SendData with or without encryption command may instruct the transactioncard 112 to transmit data using its wireless connection with, forexample, the access point 114. In addition, the data may be encrypted bythe transaction card 112 prior to transmission using, for example, keysand encryption capability stored within the security module. The ReceiveData with or without decryption command may instruct the transactioncard 112 to switch to listening mode to receive data from its wirelessconnection with the terminal/reader (e.g., access point 114). In someimplementations, data decryption can be requested by the security moduleusing, for example, keys and decryption algorithms available on thesecurity module, i.e., on-board decryption. The URL Get Data/URL PostData command may instruct the web server 306 to return pages as peroffline get or post instructions using, for example, offline URLs.

The Web server 306, as part of the OS of the transaction card 112, mayassign or otherwise associate URL style addressing to certain filesstored in the memory 326 (e.g., flash) of the transaction card 112. Insome implementations, the Web server 306 locates a file using the URLand returns the file to a browser using standard HTTP, HTTPS styletransfer. In some implementations, the definition of the files can beformatted using standard HTML, XHTML, WML and/or XML style languages.The file may include links that point to additional offline storagelocations in the memory 326 and/or Internet sites that the mobile device110 may access. In some implementations, the Web server 306 may supportsecurity protocols such as SSL. The Web server 306 may transfer anapplication in memory 326 to the mobile device 111 for installation andexecution.

As part of the Real time OS, the real-time framework 308 may execute oneor more functions based, at least in part, on one or more periods oftime. For example, the real-time framework 308 may enable an internalclock available on the CPU to provide timestamps in response to at leastrequested events. The real-time framework 308 may allow certain tasks tobe pre-scheduled such that the tasks are executed in response to atleast certain time and/or event based triggers. In some implementations,the real-time framework 308 may allow the CPU to insert delays incertain transactions. In some implementation, a part of WAP standardscalled WTAI (Wireless Telephoney Application Interface) can beimplemented to allow offline browser pages on the card 112 to make useof functions offered by the mobile device 110 (e.g., send/receivewireless data, send/receive SMS, make a voice call, play a ringtoneetc.)

The real-time OS 316 may execute or otherwise include one or more of thefollowing: real-time framework 308; a host process that implements thephysical interface between the transaction-card CPU and the mobiledevice 110; an interface that implements the physical interface betweenthe transaction-card CPU and the security module; a memory-managementprocess that implements the ISO 7816 physical interface between thetransaction-card CPU and the memory 324 and/or 326; an application-layerprocess that implements the API and UI capabilities; the Web server 306;antenna-control functions 320; power management; and/or others. In someimplementations, the real-time OS 316 may manage the physical interfacebetween the transaction-card CPU and the secure memory 324 that includesmemory segmentation to allow certain memory areas to be restrictedaccess and/or data buffers/pipes. In some implementations, the securitymodule can include a security module OS provided by the security moduleVendor and may be compliant with Visa and MasterCard specifications. Thesecurity module OS may structure the data in the security module to becompliant with Paypass and/or payWave specifications or any otheravailable contactless retail payment industry specifications. Inaddition, the security module may store host device signatures and allowmodes of the antenna 322 in the secure element 324. In someimplementations, the real-time OS 316 may include a microcontroller OSconfigured to personalizing the secure element 324 such as by, forexample, converting raw FV data (account number, expiry date, CCV, otherapplication specific details) into secure encrypted information. Inaddition, the microcontroller OS may present the card 112 as a MicroSDmass storage to the host device. The microcontroller OS may partitionthe memory into a user section and a protected device applicationsection. In this example, the device application section may be used tostore provider specific applications that either operate from thissegment of the memory or are installed on the host device from thissegment of the memory.

The security module chip may provide tamper-resistant hardware securityfunctions for encryption, authentication, management of user credentialsusing multiple security domains, on-board processing capabilities forpersonalization, access and storage, and/or others. In someimplementations, the security module chip can include the contactlesschipset 318.

The contactless chipset 318 may provides the hardware protocolimplementation and/or drivers for RF communication. For example, thecontactless chipset 318 may include on-board RF circuitry to interfacewith an external world connection using a wireless/contactlessconnection. The wireless connection may be, for example, client to node(terminal/reader/base station), node to client (passive tag), or peer topeer (another transaction card 112).

The antenna control function 320 may controls the availability of the RFantenna. For example, the antenna control function 320 mayactivate/deactivate the antenna 322 in response to, for example,successful authentication, completion of a routine established by the OS316, and/or other event. The antenna 322 may be a short range wirelessantenna connected to an NFC inlay via a software switch such as a NANDGate or other element.

The wallet management system 328 may selectively switch between themultiple credentials 314 when executing transactions. For example, thewallet management system 328 may identify a default account, switchingrules, and/or other information. In some implementations, the walletmanagement system 328 may automatically switch to default usercredentials in response to at least an event such as completion of atransaction using non-default credentials. The switching rules mayidentifying user credentials and associated events such that the walletmanagement system 328 switches to user credentials in response to atleast determining an event.

FIG. 4 is a block diagram illustrating an example intelligent card 400in accordance with some implementations of the present disclosure. Forexample, the transaction card of FIG. 1 may be implemented in accordancewith the illustrated intelligent card 400. In general, the intelligentcard 400 may independently access services and/or transactions. Theintelligent card 400 is for illustration purposes only and may includesome, all, or different elements without departing from the scope of thedisclosure.

As illustrated, the intelligent card 400 includes an antenna 402, aswitch plus tuning circuit 404, a security module and contactlesschipset 406, a CPU 408 and memory 410. The antenna 402 wirelesslytransmits and receives signals such as NFC signals. In someimplementations, the switch plus tuning circuit 404 may dynamicallyadjust the impedance of the antenna 402 to tune the transmit and/orreceive frequency. In addition, the switch plus tuning circuit 404 mayselectively switch the antenna 402 on and off in response to at least acommand from the CPU 408. In some implementations, the antenna 402 canbe a short range wireless antenna connected to an NFC inlay via asoftware switch such as an NAND Gate or other element to allow for codefrom the CPU 408 to turn the antenna 402 on and off. In someimplementations, the disk 400 may include an NFC inlay (not illustrated)that can be a passive implementation of NFC short range wirelesstechnology deriving power from the reader terminal in order to transmitdata back or a stronger implementation using an eNFC chipset to poweractive reader mode and self-train mode. In addition, the disk 400 mayinclude an external needle point reset (not illustrated) that promptsthe CPU 408 to depersonalize the memory or secure element.

The CPU 408 may transmit the switching command in response to an eventsuch as a user request, completion of a transaction, and/or others. Whenswitched on, the security chip and contactless chipset 406 is connectedto the antenna 402 and executes one or more of the following: formatsignals for wireless communication in accordance with one or moreformats; decrypt received messages and encrypt transmitted messages;authenticate user credentials locally stored in the memory 410; and/orother processes. The memory 410 may include a secure and non-securedsection. In this implementation, the secure memory 410 may store one ormore user credentials that are not accessible by the user. In addition,the memory 410 may store offline Web pages, applications, transactionhistory, and/or other data. In some implementations, the memory 410 mayinclude Flash memory from 64 MB to 32 GB. In addition, the memory 410may be partitioned into user memory and device application memory. Thechipset 406 may include a security module that is, for example Visaand/or MasterCard certified for storing financial vehicle data and/or inaccordance with global standards. In addition to a user's financialvehicle, the secure element may store signatures of allowed host devicesand/or antenna modes.

In some implementations, the CPU 408 may switch the antenna 402 betweenactive and deactivate mode based, at least in part, on a personalizationparameter defined by, for example, a user, distributor (e.g., financialinstitution, service provider), and/or others. For example, the CPU 408may activate the antenna 402 when the intelligent card 400 is physicallyconnected to a host device and when a handshake with the host device issuccessfully executed. In some implementations, the CPU 408 mayautomatically deactivate the antenna 402 when the intelligent card 400is removed from the host device. In some implementations, the antenna402 is always active such that the intelligent card 400 may be used as astand-alone access device (e.g., device on a keychain). In regards tothe handshaking process, the CPU 408 may execute one or moreauthentication processes prior to activating the intelligent card 400and/or antenna 402 as illustrated in FIG. 7. For example, the CPU 408may execute a physical authentication, a device authentication, and/or auser authentication. For example, the CPU 408 may activate the antenna402 in response to at least detecting a connection to the physicalinterface with the host device (e.g., SD interface) and successfulinstallation of the device driver for mass memory access (e.g., SDdevice driver) on the host device. In some implementations, deviceauthentication may include physical authentication in addition to asignature comparison of a device signature stored in memory (e.g.,security module) that was created during first-use (provisioning) to arun-time signature calculated using, for example, a unique parameter ofthe host device. In the event no host device signature exists in thememory, the CPU 408 may bind with the first compatible host device thedisk 400 is inserted into. A compatible host device may be a device thatcan successfully accomplish physical authentication successfully. If ahost-device signature is present in the memory, the CPU 408 compares thestored signature with the real-time signature of the current hostdevice. If the signatures match, the CPU 408 may proceed to complete thebootstrap operation. If the signatures do not match, host device isrejected, bootstrap is aborted and the disk 400 is returned to the modeit was before being inserted into the device.

User authentication may include verification of physical connection witha user using a PIN entered by the user, a x.509 type certificate that isunique to the user and stored on the host device, and/or otherprocesses. Device and user authentication may verify a physicalconnection with device through comparison of a device signature and userauthentication through verification of user PIN or certificate. In someimplementations, the user can select a PIN or certificate atprovisioning time. If this case, the CPU 408 may instantiate a softwareplug-in on the host device. For example, a software plug-in may requestthe user for his PIN in real time, read a user certificate installed onthe device (e.g., x.509), and/or others. The operation of the softwareplug-in may be customized by the provider. Regardless, the returned userdata may be compared with user data stored in the memory. In case of asuccessful match, the antenna 402 may be activated. In case of anunsuccessful match of a certificate, then disk 400 is deactivated. Incase of unsuccessful PIN match, the user may be requested to repeat PINattempts until a successful match or the number of attempts exceeds athreshold. The disk provider may customize the attempt threshold.

In regards to network authentication, the host device may be a cellphonesuch that the disk 400 may request network authentication prior toactivation. For example, the disk 400 may be distributed by a WirelessNetwork Operator (WNO) that requires a network authentication. In thisexample, a flag in memory may be set to ON indicating that networkauthentication is required. If the flag is set to ON, a unique identityabout the allowed network is locally stored in memory such a MobileNetwork Code for GSM networks, a NID for CDMA networks, a SSID forbroadband networks, and/or identifiers. If this flag is ON, the CPU 408in response to at least insertion may request a special software plug-into be downloaded to the host device and instantiated. This softwareplug-in may query the host device to respond with network details. Insome cases, the type of unique network identity employed and the methodto deduce it from the host device may be variable and dependent on thenetwork provider and capability of the host device. If thelocally-stored ID matches the request ID, the CPU 408 activated theantenna 402 to enable access or otherwise services are denied.

FIG. 5 illustrates an example transaction system 500 for wirelesslycommunicating transaction information using one of a plurality ofinterfaces. For example, the system 500 may interface the transactioncard 112 using a wired or wireless interface. In regards to wiredinterfaces, the system 500 includes an adaptor 504 and a reader 506. Theadaptor 504 can include any software, hardware, and/or firmwareconfigured to translated between a format compatible with the card 112and a format compatible with the client 104 c. For example, the adaptor504 may translate between microSD protocol and a USB protocol. Thereader 506 can include any software, hardware, and/or firmwareconfigured to directly interface with the card 112 h. For example, thereader 506 may be a microSD reader such that the client 104 d interfaceswith the card 112 h using a microSD protocol. In regards to wirelessinterfaces, the system 500 may include a cellular interface 502 and ashort-range wireless interface 508. In regards to the cellular interface502, the institutions 106 may wirelessly communicate with thetransaction card 112 e using the cellular radio technology of the mobiledevice 110 e. For example, the cellular interface 502 may be a CDMAinterface, a GSM interface, a UMTS interface, and/or other cellularinterfaces. In regards to the short-range wireless interface 508, theinstitutions 106 may wirelessly communicate with the transaction card112 f using, for example, WiFi technology. The short-range wirelessinterface 508 may be an 802.11 interface, a Bluetooth interface, and/orother wireless interface. In these implementations, the client 104 e mayinclude a transceiver used for wireless communication with thetransaction card 112 f.

FIG. 6 is a schematic diagram 600 of personalization of a intelligentcard (e.g., the transaction card 112, the service card 210). Inparticular, the intelligent card may be personalized prior to beingissued to a user, i.e., pre-issuance, or after being issued to a user,i.e., post-issuance. In regards to pre-issuance, intelligent cards maybe personalized in mass batches at, for example, a factory. In thisexample, each intelligent card may be loaded with user credentials,security framework, applications, offline Web pages, and/or other data.In some implementations, a intelligent card may be personalizedindividually at, for example, a bank branch. In this case, a intelligentcard may be individually loaded with data associated with a user after,for example, purchasing the disk. As for post issuance, the intelligentcard may be personalized wirelessly. For example, the transaction card112 may be personalized through a cellular connection established usingthe mobile device 110. In some implementations, an intelligent card maybe personalized by synchronizing with a computer such as client 104.

In some implementations, provisioning of the intelligent card can bebased, at least in part, on the distribution entity (e.g., financialinstitution, wireless operator, user). For example, the intelligent cardmay be distributed by a financial institution such as a bank. In thebank implementation, the intelligent card can be pre-provisioned withuser accounts. In this case, the intelligent card may be activated inresponse to at least initial insertion into a host device. The antennamode may be set to physical authentication only by default. In someexamples, the user may self-select a PIN authentication to preventunauthorized use or through a PC cradle and plug-in management softwareif the host device does not have a screen and keyboard. In thewireless-operator implementation, the intelligent card may requiredevice authentication before activation. In some examples, the user mayprovision financial data (e.g., credit or debit) using one of severalmethods. In addition, the user may add user authentication. In theuser-provided implementation, the user may acquire the intelligent cardfrom, for example, a retail store or other channels like OEM host devicemanufacturers. In this case, the user may activate the disk in aplurality of different devices with provider selected provisioning.

In regards to activating for financial transactions, the intelligentcard may be configured in memory mode when user acquires the disk from,for example a bank, a wireless operator, a third-party provider, and/orothers. Activation of the disk may include the following two levels: 1)physically, specifying antenna availability under a specific set ofcircumstances desired by the provider; and b) logically, at thefinancial institution signifying activation of the financial vehiclecarried on the disk. In some implementations, activation may be based,at least in part on device distributor, antenna availability selection,and/or type of host device as illustrated in Table 1 below.

TABLE 1 Plug-In Initial State Plug-in Seller and and Antenna Device HasNo Screen/ Device Has Screen & Mode of distribution Availability ChoiceKeyboard keyboard FI: Financial Plug-In is in Memory Manual: User has toIf the device is capable of Institution (bank or Mode, It is fully callFI's number to wireless access, upon retailer) ships plug-inpersonalized with user's activate his account, the insertion, theplug-in directly to the account information Device can only work spawnsa web page and subscriber or through (FV) and Antenna mode with a singleaccount. takes the user to FI's participating resellers/ is set toPhysical User can also access website. The user self distributors etc.Authentication FI's site on the internet activates his account by usinganother PC to entering his account activate his account number andmatching secret personal information (last 4 digits of SSN or home phonenumber for example). The user can also optionally select a PIN (changeAntenna availability to user authentication) at the same time. IfInternet connection is not available, the device can automatically diala voice call to FI's number for account activation. If wirelessconnection is not available as well (device is only a PDA), the user hasto fallback to manual activation (see left) WNO: Wireless Plug-In is inMemory Not Applicable Assumption: Device has a Network Operator Mode, itis partially functional wireless Ships plug-in bundled personalized(device connection. Operator with host device, User signature of thehost offers a bundled wallet can select his preferred device loaded toprevent management application. host device and plugin user fromchanging host When user clicks the is bundled with it if device) whileFV wallet management user would like to information is not application,the user is avail of this service loaded. Antenna invited to sign-upwith Availability is set to operator's partner FI for a DeviceAuthentication new account. Once sign- (plug-in can only used up issuccessful, account with host device it is data is downloaded Overshipped with) the Air or Over the Internet to the plugin and it isactivated for use Device can use multiple FIs in this scenario and storemultiple FVs. User can select to enter a PIN for an FV in the walletmanagement application in order to convert Antenna availability to userand device authentication for that FV Plug-in is bound to a devicesignature. When removed from the device, the Antenna turns off and theplug-in turns into a simple mass memory stick. When Plug-in is insertedinto another host device, the signature doesn't match and Antennaremains off. WNO: Wireless Plug-In is in Memory Not ApplicableAssumption: Device has Network Operator Mode, it is functional wirelessShips plug-in as an unpersonalized. Antenna connection. Plug-In willaccessory with an Availability is set to spawn an internet advice forcompatible Network authentication connection to the operator devices,User can is set to On. Plug-In will portal and the wallet select hispreferred bind to first device it is management application host deviceand inserted in and where will be downloaded upon attempt to operate hisnetwork authentication is user confirmation. User plug-in with, to availsuccessful can reject download and of the service choose to manuallyprovision FV data by going to a third party wallet provider or directlyto the FI website. Plug-In is bound to the device and to the networkprovider's network. If the same device is unlocked and used on anothernetwork, the plug-in will cease to operate and will revert back tomemory mode. When removed from the device, the plug-in will revert tothe memory mode. OEM 1: Cellphone Device Authentication Not ApplicableOption A: Device manufacturer (device comes bundled Manufacturer offersa with a cellphone) wallet management application, rest of the processremains as above Option B: Wireless Operator offers a wallet managementapplication. User goes to the wireless operator portal and downloadsthis application Over the Air. The rest of the process then remains thesame as above Option C: User navigates to a third party walletmanagement application (example paypal or Google). Sign up is offered toparticipating FIs and FVs are personalized on the plug-in Over theInternet Option D: User navigates to FI's website and activates a newaccount which is personalized over the Internet on the plug-in OEM 2:Other Device Authentication User has to cradle the If the device haswireless manufacturer device to the PC with connection (it is a wirelessan internet connection PDA): Same as above If and sign-up on the PC thedevice has no wireless by going to an FI's connection (it is an websitedirectly. unconnected PDA): Same Account is downloaded as left over theinternet via the cradle and then the device is activated. In thisprocess, the plug-in is bound to the device signature. When removed fromthe host device, the antenna turns off When plugged into another device,the device signature fails and the device behaves like a mass memorydevice onlyThe illustrated chart is for example purposes only. The user mayactivate an intelligent card using the same, some, or differentprocesses without departing from the scope of this disclosure.

In the illustrated implementations, the transaction card 112 may beupgraded to execute a wallet system using multiple user credentials. Forexample, the transaction card 112 may upgraded with, for example, thewallet management system 328 through a wireless or wired connection. Inaddition to upgrading the transaction card 112, additional usercredentials may be loaded to the memory. In this case, the transactioncard 112 may selectively switch between the different user credentialsbased, at least in part, on rules, user selections, events, and/or otheraspects.

FIG. 7 is a flow chart illustrating an example method 700 forautomatically bootstrapping an intelligent card in response to at leastinsertion into a host device. In general, an intelligent card mayexecute one or more authentication procedures prior to activation. Manyof the steps in this flowchart may take place simultaneously and/or indifferent orders as shown. System 100 or system 200 may use methods withadditional steps, fewer steps, and/or different steps, so long as themethods remain appropriate.

Method 700 begins at step 702 where insertion into a host device isdetected. For example, the transaction card 112 may detect insertioninto the mobile device 110. If authentication is not required for anyaspect of the intelligent card at decisional step 704, then executionends. If authentication is required for at least one aspect, thenexecution proceeds to decisional step 706. If communication with thehost device includes one or more errors, then, at step 708, a failure isindicated to the user. In the example, the transaction card 112 maypresent an indication of a communication error to the user using the GUI111. If a communication error is not detected at decisional step 706,then execution proceeds to decisional step 710. In some implementations,the intelligent card uploads an SD driver to the host device. If theintelligent card only requires physical authentication, then executionproceeds to decisional step 712. If the network authentication flag isnot set to on, then, at step 714, the antenna is turned on and theintelligent card is updated with host-device signature. As for theexample, the transaction card 112 may activate the antenna for wirelesstransactions and update local memory with the host-device signature. Ifthe network authentication flag is turned on at decisional step 712,then, at step 716, the intelligent card transmits a request for thenetwork ID to the host device. Next, at step 718, the intelligent cardretrieves a locally-stored network ID. If the stored network ID and therequest network ID match at decisional step 720, then the disk isactivated at step 714. If the two network ID's do not match, then theantenna is deactivated at step 722.

Returning to decisional step 710, if the authentication is not onlyphysical authentication, then execution proceeds to decisional step 724.If the authentication process includes device authentication, then, atstep 726, the intelligent card transmits a request for a network ID tothe host device. At step 728, the intelligent card retrieves a locallystored device signatures. If the intelligent card does not include atleast one device signature, then execution proceeds to decisional step734. If the intelligent card includes one or more device signatures,then execution proceeds to decisional step 732. If one of the devicesignatures matches the request network ID, then execution proceeds todecisional step 734. If the signatures and the request network ID do notmatch, then execution proceeds to step 722 for deactivation. If userauthentication is not included in the authentication process, thenexecution proceeds to decisional step 712 for physical authentication.If user authentication is included at decisional step 734, thenexecution proceeds to step 738.

Returning to decisional step 724, if the authentication process does notinclude device authentication, then execution proceeds to decisionalstep 736. If user authentication is not included in the process, then,at step 722, the intelligent card is turned off. If user authenticationis included, then, at step 738, the intelligent card request a PINnumber from the user using the host device. Again returning to theexample, the transaction card 112 may present a request for the user toenter a PIN through the GUI 111. At step 740, the intelligent cardretrieves a locally-stored PIN. If the request PIN and stored PIN matchat decisional step 742, then execution proceeds to decisional step 712for physical authentication. If the request PIN and the stored PIN donot match at decisional step 742, then execution proceeds to decisionalstep 744. If the number of attempts have not exceeded a specifiedthreshold, then execution returns to step 738. If the number of attemptshas exceed to the threshold, then the antenna is deactivated at step722.

FIG. 8 is an example call flow 800 in accordance with someimplementations of the present disclosure. As illustrated, the flow 800includes a network 802, a host device 804, an intelligent card 806, anda terminal 808. The host device 804 is configured to communicate withthe network 802 and includes a slot for insertion of the intelligentcard 806. The intelligent card 806 is configured to transmit commands toand receive data from a user interface application 810 executed by thehost device 810 and execute transactions independent of the host device810. The card 806 includes a CPU 812 for executing transactions and awireless chipset 814 for communicating with the terminal 808. The CPU812 executes a host controller/API interface 816 configured to transmitscommands in a form compatible with the host device 804 and convert datafrom the host device 804 to a form compatible with the CPU 812.

As illustrated, the flow 800 may include multiple sessions 820 betweenthe host device 804 and the card 806 and between the card 806 and theterminal 808. The session 820 a illustrates a session managed by thecard 806 using the network capabilities of the host device 810. In thisexample, the card 806 transmits data for transmission through a cellularnetwork connected to the host device 804, and after receiving thecellular data, the host device 804 transmits the data to the network802. In response to receiving data from the network 802, the host device804 may automatically transmit the received data to the card 806. Insome implementations, the card 806 may transmit a request for a devicesignature to the host device 804 as illustrated in session 820 b. Forexample, the card 806 may request the device signature during abootstrapping process. The session 820 c illustrates that a user maysubmit commands to the card 806 through the interface of the host device804. For example, the user may request that the disk display the user'stransaction history through the interface of the host device 804.

In some implementations, the card 806 may receive a command to activateor deactivate the antenna through the host device 804 as illustrated insession 820 d. For example, a financial institution may identifyirregular transactions and transmit a command through the network 802 todeactivate the card 806. The card 806 may authorize a user by requestinga PIN using the host device 804. As illustrated in session 820 e, theuser may submit a PIN to the card 806 using the interface of the hostdevice 804, and in response to an evaluation of the submitted PIN, thecard 806 may present through the host device 804 an indication that theuser verification is successful or has failed. In some implementations,a user and/or financial institution may request a transaction history ofthe card 806 as illustrated in session 820 f. For example, a financialinstitution may transmit a request for the transaction history throughthe network 802 connected to the host device 804, and in response to atlast in the request, the card 806 may transmit the transaction historyto the financial institution using the network 802 connected to the hostdevice 804. In some implementations, the user may present offline Webpages stored in the card 806 as illustrated in session 820. For example,the card 806 may receive a request to present an offline Web page fromthe user using the host device 804 and present the offline page usingthe URL in the request. In some implementations, data stored in thememory of the card 806 may be presented through, for example, the hostdevice 804 as illustrated in session 820 h. For example, the user mayrequest specific information associated with a transaction on a certaindata and the card 806 may retrieve the data and present the data to theuser using the host device 804. In addition, the user may write data tothe memory in the card 806 as illustrated in session 820 i. For example,the user may update transaction data with an annotation, and in responseto at least the request, the card 806 may indicate whether the updatewas a success or failure. The call session 820 m illustrates thatselection of the user credentials may be received through the hostdevice 804. For example, the session 820 m may switch the usercredentials based, at least in part, on a user selecting a graphicalelement through a GUI of the device 804, wireless signal received by thehost device 804, and/or others.

In regards to session between the card 806 and the terminal, the flow800 illustrates the personalization session 820 k and the transactionsession 820 l. In regards to personalization, a financial institutionmay personalize a card 806 with user credentials, user applications, Webpages, and/or other information as illustrated in session 820 k. Forexample, the terminal 808 may transmit a provisioning request to thecard 806 including associated data. The protocol translation 818 maytranslate the personalization request to a form compatible with the card806. In response to at least the request, the CPU 812 transmit anindication whether the personalization was a success or not using theprotocol translation 818. Prior to the terminal executing a transaction,the terminal 808 may submit a transaction challenge to the card 806 asillustrated in session 820 l. In this case, the card 806 may identify adevice signature of the host device 804, present associated data to theuser through the host device 804, and transmit the signature to theterminal 808 using the protocol translation 818.

FIG. 9 is a flow chart illustrating an example method 900 for activatinga wireless transaction system including an intelligent card. In general,an intelligent card may execute one or more activation processes inresponse to, for example, a selection from a user. Many of the steps inthis flowchart may take place simultaneously and/or in different ordersas shown. System 100 or system 200 may use methods with additionalsteps, fewer steps, and/or different steps, so long as the methodsremain appropriate.

Method 900 begins at step 902 where a request to activate a transactioncard is received. For example, the user may select a graphical elementdisplayed through the GUI 111 of a mobile host device 110 in FIG. 1. Ifan account activation is included at decisional step 904, then at step906, a request to activate the associated user account is wirelesslytransmitted to financial institution using cellular radio technology ofthe host device. For example, the transaction card 112 d of FIG. 2 maywireless transmit an activation request to the institution 106 using thecellular radio technology of the mobile host device 110 d. If an accountactivation is not included, then execution proceeds to decisional step908. If card activation is not included, then execution ends. If cardactivation is included, then execution proceeds to decisional step 910.If an activation code is not included, then at step 912, one or morepreprogrammed questions are presented to the user using the GUI of thehost device. Returning to the initial example, the transaction card 112may identify locally stored questions and present the questions to theuser using the GUI 111 of the mobile host device 110. At step 914,locally-stored answers to the programmed questions are identified.Returning to decisional step 910, if an activation code is included,then execution proceeds to decisional step 916. If the activation codeis manually entered by the user, then at step 918, a request for theactivation code is presented to the user through the GUI of the mobilehost device. In the initial example, the transaction card 112 maypresent a request for an activation code such as a string of charactersto the user through the GUI 111 of the mobile host device 110. If theactivation code is not manually entered by the user, then at step 920,the transaction card wirelessly transmits a request for the activationcode using the cellular radio technology of the host device. In thecellular example, the transaction card 112 may transmit a request to thefinancial institution using the cellular core network 202. In eithercase, the locally-stored activation code is identified at step 922. Ifthe locally stored information matches the provided information atdecisional step 924, then at step 926, the transaction card isactivated. For example, the transaction card 112 may activate inresponse to at least a user entering a matching activation code throughthe GUI 111. If the provided information does not match the locallystored information, then execution ends.

FIG. 10 illustrates example secure memory 1000 in accordance with someimplementations of the present disclosure. In general, the secure memory1000 is configured to store user credentials for a plurality ofdifferent financial institutions. For example, each credential may beassociated with a different user account (e.g., credit card, bankaccount). In the illustrated implementation, the secure memory 1000includes user credentials 1002 a-c and associated security frameworks1006 a-c separated by logical barriers 1010-c. In addition, the securememory 1000 includes master credentials 1004 and a master securityframework 1008. Each user credentials 1002 may be associated with adifferent user account and/or institution. For each user credential 1002is assigned or otherwise associated with a security framework 1006. Thesecurity framework 1006 may be a payment application executed by theintelligent card in response to at least a selection of a user account.For example, the security framework 1006 may execute transactions inaccordance with a specified format, protocol, encryption, and/or otheraspects of an authorization request. In some implementations, thesecurity framework 1006 can substantially prevent unauthorized access touser credentials. For example, each security framework 1006 may containmultiple keys that provide different levels of access. Each applicationwithin the framework 1006 may then be configured to be accessibleaccording to particular security levels. In some implementations, thesecurity frameworks 1006 may include different versions of a paymentapplication for a type of financial instrument (e.g., Visa). In someimplementations, the security framework 1006 may be identified using anapplication ID.

The master credential 1004 and the master security framework 1008 mayenable financial institutions to store or update user credentials 1002and associated security frameworks 1006. For example, creation of a newkey within a security framework 1006 may be protected by the masterframework's root key. The barriers 1010 may generate security domainsbetween the different selectable user credentials 502 and associatedsecurity framework 1006. For example, a financial institution may accessuser credentials 1002 and associated security framework 1006 for amanaged user account but may be substantially prevented from accessinguser credentials 1002 and associated security framework 1006 fordifferent financial institutions.

In some implementations, the intelligent card (e.g., transaction card112) can dynamically switch between user credentials 1002 and securityframeworks 1006 in response to at least an event. For example, theintelligent card may switch to default user credentials 1002 and thecorresponding security framework 1006 upon completion of a transaction.In some implementations, the intelligent card may switch usercredentials 1002 and security frameworks 1006 in response to a selectionfrom a user through, for example, the GUI 111 of FIG. 1. The intelligentcard may typically switch between different user accounts based, atleast in part, on different circumstances. In regards to addingadditional user accounts, a user may manually enter user credentials1002 using the GUI of a host device. In some implementations, the memory1000 may be updated OTA using the cellular radio technology of the hostdevice.

FIG. 11 is a flow chart illustrating an example method 1100 fordynamically switching between user accounts. In general, an intelligentcard may dynamically switch between a plurality of selectable usercredentials and associated security frameworks in response to at leastan event. Many of the steps in this flowchart may take placesimultaneously and/or in different orders as shown. System 100 or system200 may use methods with additional steps, fewer steps, and/or differentsteps, so long as the methods remain appropriate.

The method 1100 begins at step 1102 where an event is identified. Forexample, the transaction card 112 of FIG. 1 may determine that one ormore of the following has been updated: network ID, phone number, MACaddress, and/or other information. In some implementations, the eventmay include identifying one or more aspects of a transaction orpotential transaction. For example, the transaction card 112 maydetermine an enterprise, type of enterprise, goods and/or services,types of goods and/or services, and/or other aspects. At step 1104, thecurrently selected user account is determined. In the example, thetransaction card 112 may determine the currently selected usercredentials and security framework. If the user accounts are switched atdecisional step 1106, then at step 1108, the intelligent carddynamically switches the currently selected user account to a differentuser account based, at least in part, on the identified event. Again inthe example, the transaction card 112 may dynamically switch between theplurality of selectable user accounts based, at least in part, on one ormore events. Next, at step 1110, a request to execute is received. Asfor the example, the transaction card 112 may directly receive awireless request to execute a transaction with the access point 114. Inresponse to at least the request, a request to execute the transactionis presented to the user at step 1112. In the example, the transactioncard 112 may present the request to the user through the GUI 111 of themobile host device 110. In some implementations, the transaction card112 may present the currently selected user account to user through theGUI 111. At step 1114, the request transaction is executed using theselected user credentials and corresponding security framework inresponse to at least a selection from the user. Again in the example,the transaction card 112 may execute the request transaction in responseto at least a user selecting a graphical element in the GUI 111 of themobile host device 110 and wirelessly transmit the authorization requestdirectly to the access point 114. If the selection of account isswitched to a default account at decisional step 1116, the intelligentcard automatically switches the selected user account to default usercredentials and corresponding security framework. If the selection isnot switched to a default account, then execution ends.

A number of embodiments of the invention have been described.Nevertheless, it will be understood that various modifications may bemade without departing from the spirit and scope of the invention.Accordingly, other embodiments are within the scope of the followingclaims.

1-26. (canceled) 27-40. (canceled)
 41. A portable device, comprising: aconnection to a display including a Graphical User Interface (GUI); aconnection to a cellular transceiver that communicates with a cellularnetwork; a Near Field Communication (NFC) module including an NFCantenna; one or more processors configured to: store, in secure memory,user credentials used to execute transactions with contactless devicesand are associated with one or more enterprises, the secure memoryincludes master credentials and a master security framework that enableenterprises to store or update user credentials and associated securityframeworks; dynamically generate screens associated with the usercredentials and presents the dynamically-generated screens on thedisplay through the GUI; where-in the portable device can: executewireless transactions with contactless devices using the usercredentials and the NFC antenna; and selectively switch the NFC featurefrom an active state to an inactive state in response to at least anevent.
 42. The portable device of claim 41, where-in certain portabledevices are configured without their own displays and cellularconnections but are attached or paired with a mobile device using aphysical or a wireless connection.
 43. The portable device of claim 41,wherein the secure memory stores a plurality of security frameworks forthe user credentials, the transaction module executes requestedtransactions using security frameworks from the plurality of securityframeworks.
 44. The portable device of claim 41, wherein the wirelesstransactions are executed in response to at least user selectionsthrough the dynamically-generated displays.
 45. The portable device ofclaim 41, wherein the dynamically-generated displays present informationbased, at least in part, on at least one of real-time content duringtransactions, locally-stored offline content, or online contentretrieved from the one or more enterprises.
 46. The portable device ofclaim 41, wherein the user-interface module further presents a requestfor user identification including at least one of a PersonalIdentification Number (PIN), user ID and password, or biometricauthentication through a mobile device, the portable device furtherverifies the submitted user identification with user identificationlocally stored in the secure memory prior to executing requestedtransactions.
 47. The portable device of claim 41, the one or moreprocessors further configured to decrypt received signals prior toprocessing by the processor and encrypts at least part of thetransaction response prior to wireless transmission.
 48. The portabledevice of claim 41, wherein the event comprises failure to authenticatethe cellular network or a command from a financial institutionassociated with the user credential received through the cellulartransceiver.
 49. The portable device of claim 41, the one or moreprocessors configured to activate access to user credentials andtransmits, using cellular transceiver, to an associated financialinstitution a request to activate an associated user account.
 50. Theportable device of claim 49, wherein access to user credentials isactivated based, at least in part, on a user manually entering anactivation code using the GUI of the mobile device.
 51. The portabledevice of claim 41, wherein the user of the mobile device managesdifferent user accounts associated with the user credentials using theGUI.
 52. The portable device of claim 41, the one or more processorsfurther configured to receive requests to update the user credentialsthrough the cellular transceiver of the mobile device or a wiredconnection with a broadband network.
 53. The portable device of claim41, the credentials module further configured to at least add new setsof user credentials or delete existing user credentials based, at leastin part, on the update requests.
 54. The portable device of claim 41,wherein the user credentials include a default user credentials, the oneor more processors further configured to use the default usercredentials after at least completing a requested transaction usingdifferent user credentials or expiration of a period of time to completea transaction using non-default user credentials.
 55. The portabledevice of claim 41, wherein user credentials are loaded into the securememory from a plurality of different enterprises.